home *** CD-ROM | disk | FTP | other *** search
- Path: in2.uu.net!bounce-back
- Date: 10 Jan 96 08:19:26 GMT
- Approved: fjh@cs.mu.oz.au
- From: jason@cygnus.com (Jason Merrill)
- Newsgroups: comp.std.c++
- Subject: string implementation (was: ANSI/ISO Exception Hierarchy)
- X-Original-Date: 09 Jan 1996 12:54:37 -0800
- Organization: Cygnus Support, Mountain View, CA
- Message-ID: <u9ohsdozqq.fsf_-_@yorick.cygnus.com>
- References: <4cgog4$jsq@netlab.cs.rpi.edu> <4cipio$pcj@netlab.cs.rpi.edu>
- <4crabd$91f@netlab.cs.rpi.edu> <4cteo4$32o@netlab.cs.rpi.edu>
- <KANZE.96Jan9165545@slsvewt.lts.sel.alcatel.de>
- In-Reply-To: kanze@lts.sel.alcatel.de's message of 09 Jan 1996 15:55:45 GMT
- X-Newsreader: Gnus v5.0
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBFAgUBMPN2uuEDnX0m9pzZAQGTEAF/Z1xgdNLccYZgOmcI0l9iqNB8iphoX0fj
- JEZDB8hO6RXUvJN4YR67WEAlab/s5Qi/
- =2TNg
-
- >>>>> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:
-
- > In article <4cteo4$32o@netlab.cs.rpi.edu>
- > Etay_Bogner@mail.stil.scitex.com (Etay Bogner) writes:
-
- > |> I believe that the string class would best implememnted as a
- > |> copy-on-change class, which means that the copy-constructor will not
- > |> actually duplicate the string but will increase the reference counter it
- > |> uses.
-
- > I don't believe that copy on write is allowed in the current draft.
- > Each string can have its own unique allocator; how do you implement
- > copy on write in such cases?
-
- I don't see why specifying the allocator would have any effect on COW.
- Whether a representation can be shared is independent of what method was
- used to allocate the storage for that representation.
-
- > Even if copy on write were allowed, I can think of many reasonable
- > implementations in which string::data() (or string::c_str()) may throw
- > bad_alloc. Maintaining the physical data internally as a contiguous
- > buffer makes most of the string manipulation functions relatively
- > expensive on long strings. (Since I only use very short strings, this
- > doesn't bother me. But it is a point that an implementor may want to
- > consider.)
-
- I was going to tell you that the types of the iterators precluded any other
- representation, but happily it looks like that was changed in the September
- WP: from
-
- typedef typename Allocator::types<charT>::pointer iterator;
- typedef typename Allocator::types<charT>::const_pointer const_iterator;
-
- to
-
- typedef implementation_defined iterator;
- typedef implementation_defined const_iterator;
-
- This also gives COW implementations more flexibility.
-
- Jason
- ---
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-